1. Field of Invention
The present invention relates generally to techniques for increasing performance efficiencies of memory management techniques in computing environments, and particularly to methods for more efficiently executing memory allocations and frees between the native system libraries and the (operating system) kernel providing for improved utilization of memory-space in a manner transparent to user programs.
2. Description of Prior Art
Generally, computer systems can be thought of having two types of memory, operating system memory (or kernel mode memory) and user memory, the kernel memory comprising that portion of memory utilized for operating system execution including basic functions as physical memory management and controlling execution of one or more user programs or processes; and, a user memory (comprising a logical address or user space) where user programs, processes and/or data operate.
Before a CPU can execute a program, the user's memory has to be loaded into a physical address space; that is, so it may be directly accessed by the CPU for execution. Additionally, all logical addresses must be mapped to produce physical addresses that the operating system tracks. Thus, a program generated address or “logical address” consisting of a logical page number plus a location within that page is interpreted or “mapped” onto an actual (physical) main memory address by the operating system using a mapping or address translation function. As known, this function is typically embodied as a page table including associative registers and/or translation lookaside buffers (TLBs) that facilitate the retrieval of a physical address corresponding to a logical page and, that includes an access code (e.g., one or more “dirty” bits) to indicate its presence in main memory. If the page is present in the main memory, the mapping mechanism substitutes a physical page frame number for the logical number. If the mapping mechanism detects that the page requested is not present in main memory, a “fault” occurs and the page must be read into a frame in main memory from a secondary storage device.
Furthermore, the operating system typically keeps a table indicating which parts of memory are available and which are occupied. In dynamic storage allocations schemes, when a user process arrives, typically a C library function is implemented to allocate as much memory as is needed to run the process. When a process is allocated space, it is loaded into user memory and can then compete for the CPU processing; and when a process terminates, the memory is released or freed which the O/S can fill with another process. Typically, computer systems implement a partitioning approach whereby the physical memory comprises fixed-size memory blocks, e.g., frames, with memory units, i.e., pages, allocated based on block size. Thus, when a process is to be executed, its pages are loaded in available memory frames. Memory frames and pages sizes may range from between 512 bytes to 16 Mbytes, with typical architectures supporting memory frame sizes of 4 kB or 8 kB.
It is often the case that the memory requirements of a process do not coincide with page boundaries, e.g., a physical memory frame allocated will not be completely frill leading to an internal fragmentation condition. This is illustrated in FIG. 1A illustrating the granularity of example physical memory allocations requested of the kernel by a C library function for user processes in fixed size memory page frames of 4 kBytes for example. Thus, as shown in FIG. 1A, an executing user process has been allocated three (3) 200 bytes memory portions 12, for example, that are mapped to a memory page 10. As shown the frame is not completely filled (an internal fragmentation condition). In another instance, as shown in FIG. 1A, a process has been allocated a 400 byte memory portion 22 mapped to a page frame 20. However, in this instance, the same process has allocated additional memory 32, e.g., of 5 kBytes in length, that is mapped in part to page frame 20 and the remainder to a second page frame 30. Thus, in this instance, the page frame 20 shares another memory allocation for the same process. The portion of the allocated memory portion 32 not stored in page frame 20, is mapped to memory frame 30. In the last example shown in FIG. 1A, a process 42, for example, has been allocated memory 42 of 10 kB and is mapped to page frames 40, 50 and 60. It is understood that, of allocations 12, 22, 32, 42 shown in FIG. 1A may be attributed to a single process.
It is the case that physical memory page frames that share memory allocations, e.g., page frame 20, can only be recycled as free memory when both of the user memory allocations are freed, i.e., released by a C library system call to the kernel. The O/S tracks the freed memory in a “Global” free page pool. Thus, the kernel must check if there are any other allocations remaining in the same page before it can put the page out for recycling.
FIG. 1B shows an example instance of pages 20 and 30 marked as recyclable pages 25 and 35 using a function MADVISE_DONTNEED, or equivalent function call, which indicates to the kernel that the page can be immediately reused, e.g., either by the same process, or any other process sharing the memory pool.
Currently, it is necessary in the memory allocation and freeing implementations described, that the data in recycled memory pages be “cleaned out” for security purposes—typically by having the kernel “zero out” the memory page, which is a processing overhead. That is, data resident in recycled memory pages must be zeroed in order to prevent one user from seeing the memory used by another user. However, in an attempt to avoid multiple free and clean cycles (e.g., between the C library and O/S), it is desirable to prevent the freeing of memory pages back to the operating system global free page pool.
It would be highly desirable to provide modifications to the O/S system kernel and system library memory allocation and freeing routines that create efficiencies when an application (through a system library call) allocates new memory for processes.
It would be highly desirable to provide modifications to the O/S system kernel and system library memory allocation and freeing routines while preventing users from seeing another user's confidential data when a memory page is allocated having data previously stored at that memory page by a prior process.
It would be further highly desirable to provide modifications to the O/S system kernel and system library memory allocation and freeing routines by creating one or more types of free memory page “pools” and using these pools to reduce the overhead of allocating memory pages to processes.